Celestin Apprentice 2/Apprentice-Release2.iso/Source Code/C/Games/Xconq 7.0d16/doc/play.texi

Text File | 1993-12-20 | 45.3 KB | 1,202 lines | [TEXT/MPS ]

@node Playing Xconq, Game Design, Acknowledgments, Top

@chapter Playing Xconq

This chapter is about how to play @i{Xconq}.
Although @i{Xconq} supports a wide variety of games,
and runs on many different computer systems,
they all have much in common,
and it is these common features that will be described here.
This chapter, along with the document for your system
and the document for the game you're playing,
should provide all the information you need to play
and enjoy @i{Xconq}.

The term @dfn{interface} refers to the particular graphical user
interface in use.  Examples include X11 basic, X11 toolkit, curses,
Macintosh(tm), and ``dumb terminal'' (used for testing).
Interfaces can vary radically from each other, since each is designed
to be best suited for its environment.
However, all have some way to display the world, all have a way to
examine individual units, and all provide some way for
you to make your units do actions.
In practice, interfaces will also tend to share the same commands,
so that you don't learn to learn a whole new set of commands when
switching computers.

When reading this chapter, you should be aware that the term
@dfn{game} is more precisely @dfn{game design}, since it is
the set of rules and definitions of the game you want
to play.  Since @i{Xconq} allows for many different kinds of
games designs, much of the information in this chapter will
be irrelevant to a particular game.  This will be indicated
by phrases like ``some games'' or by saying that a game ``may''
implement some concept or behavior.  You should learn what
the game you're playing actually does in these cases.
The names of the variables or tables to look at will often
be mentioned in @code{computer type} like this.

@node Setting Up, Starting Play, Xconq Games, Playing Xconq

@section Setting Up A Game

To get started with an @i{Xconq} game,
you have to select the one that you want to play.
The possibilities may be
presented to you, or you may have to look in some sort of library
to see what's available and then supply that name on a command line.
If you don't do anything, then you will get some sort of default game.

Some games require no additional setup;
once loaded, you're ready to go.
Others will require additional decisions,
such as the size and shape of the playing area,
whether exploration will be necessary, or
whether the game is realtime.
These will all be called @dfn{variants}.
The exact set of variants is determined by the game design,
and the interface will (usually) tell you about them.

In addition, most games also give you a choice of
which player is to play which side in a game,
as well how many players can join in.
There are two kinds of players: humans, who have displays,
and artificial intelligences or AIs for short, which are
run by the computer.  Your version of @i{Xconq} may support
more than one kind of AI; each type has a distinct name.

An example might be a simulation of pre-WWI Europe,
named @code{"la-belle-epoque"}, in which the
sides might be ``England'', ``France'', ``Germany'',
and ``Austria-Hungary'', and
the players might be Joe on a Sun-4, Natalie on a Mac, and
two of the @code{mplayer} type AIs.  You can set
Natalie to play England, Joe to play Germany, and the two AIs
to play France and Austria-Hungary.

Some game designs provide a way to even things up if the players
are of vastly differing abilities.
In these designs, each player has an @dfn{initial advantage} that affects
how much he or she gets to start with.
Weaker players should get a
higher advantage, so for instance a game of two players of advantages
1 and 4 might give the advantage 4 player 8 cities while the advantage 1
player gets only 2.
This affects setup only; during the game all players are equal.
The variability of advantage also depends on the game; some may
allows differences of 10 to 1 or more, while others, especially
historically accurate scenarios, will have a fixed advantage that
the designer has set for each side.

Once a trial player setup has been made,
@i{Xconq} runs ``synthesis methods''.
These methods are specified by the game design,
and randomly generate anything that was not explicitly spelled out;
for instance, the initial location of countries, terrain features,
and so forth.
As a player, you don't have to concern yourself about synthesis
methods, but you should be aware that
you may sometimes run into situations were a synthesis method simply cannot
cope, and your game setup will fail.  A common case is where you
ask for many players to be set up in a small world, and the
set of constraints is too ``tight'' for an initial setup to
succeed.  In such cases, you just have to try different setups
and maybe complain to the game designer (or to the @i{Xconq} author!).
Synthesis methods may also take a long time to run; for large worlds
and lots of players, be prepared to wait.

When initialization and setup succeeds, @i{Xconq} will try to open up
displays for every player that wanted one.
Exactly how this happens depends on the interface and networking
capabilities of the version of @i{Xconq} you're using.
Once this is done, @i{Xconq} will start the game for real.

[any other setup warnings to document?]

@subsection Mixing Game Modules

Some interfaces (such as those using Unix-style command lines) may let you
ask for more than one game design when starting up.
This is sometimes useful, for instance, if you want to play on
the @code{steppes} world with a non-standard set of units;
your command line might look like @code{-g my-hacks -g steppes}.
Be aware, however, that this cannot be guaranteed to work always,
since the mixed-together game designs may have
mutually conflicting definitions, or interfere with
each other in subtle or not-so-subtle ways.  Just imagine the disaster
if the world consists entirely of terrain that is instant death to your
initial units!  Worse, @i{Xconq} may start up and run OK for awhile,
then crash and burn for no apparent reason.

So be careful about mixing designs!

@node Starting Play, Worlds, Setting Up, Playing Xconq

@section Starting Play

Exactly what you'll first see depends entirely on the interface you're using.
Help is available in the ``usual'' ways,
and the interface is robust, so you can always just try
to find your way around by experimentation.
(This is best done by yourself, rather than in a game with a lot
of other people.)

The game proceeds as a sequence of @dfn{turns}.
During each turn, you and the other players get to move
your @dfn{units}, which can be anything from cities to submarines
to insects, depending on the game.
In addition, there may be @dfn{backdrop activities},
such as changing seasons and weather, that go on all by themselves.
These typically happen at the beginning or end of a turn,
not while players are moving their units.

Your exact goal in the game depends on the @dfn{scorekeepers}.
Most games have at least one, some have several, and some have none.
There are many kinds of scorekeepers, so be sure you know and
understand what they are before getting too far into a game!
There may not be any scorekeepers at all, in which case you can
do whatever you like; any AIs playing in such a game will also
do what they like.

A game may last anywhere from a few turns to many hundreds.
Again, this may be limited by the game design,
or perhaps by the nature of the game.  For instance, a game
of oil empires might be forced to end when the world's oil
supplies are exhausted...

@node Worlds, Units, Starting Play, Playing Xconq

@section Worlds and Areas

@quotation
Gallia est omnis divisa in partes tres [All Gaul is divided into three
parts] -- JULIUS CAESAR
@end quotation

The @i{Xconq} ``world'' is always a sphere.  However, you only play
on a piece of it, which is called an @dfn{area}.
Currently, there can only be one world and one area in a game.

An area is divided into hexagonal @dfn{cells}.  Although squares
with four or eight neighbors could be used (and were, in the very first
version of @i{Xconq}), hexes have better all-around geometric properties.
Each cell is adjacent to six others,
in the directions NW, NE, W, E, SW, and SE.
Areas have a @dfn{width} and @dfn{height} that are the number
of cells across and up/down.
Although you can ask for areas down to 10x10 or less,
or up to 1000x1000 or even more, the ideal default is typically
around 60x30.  Larger areas consume vast quantities of memory,
plus they're slow and unwieldy to play on.

An area may be large enough to go all around the world, forming
a cylinder shape.
The cylinder can be circumnavigated in an east-west direction.
This is an 8x6 cylinder:
@example
# # # # # # # #
 : : + + : : : :
: : : + ^ : : :
 : : : : : : : :
: : : : ^ : : :
 # # # # # # # #
@end example

Areas whose width is less than the world's circumference
have a hexagonal shape.
This is an 8x7 hexagon:
@example
   # # # # #
  # : + + : #
 # : : + ^ : #
# : : + ^ : : #
 # : : : : : #
  # : : ^ : #
   # # # # #
@end example

The top and bottom rows of the cylinder shape,
and all the sides of the hexagon shape, although
they are displayed, may not be entered (except when leaving the world
entirely, see below).  These cells are called @dfn{edge} cells.

The types of terrain you'll find in the world depends on the game design;
typically there will be sea, land, mountains, swamp, and so forth,
but more exotic games have been known to
feature junkheaps, lava, and black holes as ``terrain''.

Terrain can appear either to cover an entire cell or as linear features
passing through or between cells.
@dfn{Cell terrain} covers the entire cell uniformly,
right out to its edges.
A @dfn{border} is the boundary between two adjacent cells;
it has a distinct terrain type, such as ``river'' or ``beach''.
A @dfn{connection} is a narrow ribbon of terrain that reaches
from the middle of one cell to the middle of an adjacent cell.
Like borders, connections are distinct types, for instance ``road'',
``railway'', or ``canal''.
Connections take precedence over borders and underlying cell terrain;
in other words, if cell or border terrain is impassable, but there is
a passable connection type, then the connection allows passage.
Thus a connection can be usable as a bridge.

You may also find more than one type of connection or border,
between two cells, such as both a road and a rail line.
This occurs only in the more complex games.

A @dfn{coating} is like snow; it is a type that co-exists with
cell terrain.  Coatings can change from turn to turn, varying
in depth.

Note that any single terrain type can only play one of these roles.
This means you will never have river terrain that is both border
and connection, nor will snow be both a coating and a cell type.

In some games, each cell has an @dfn{elevation}, which is basically
elevation above sea level, but could be any range of values, as set
by the game design.
The game design also defines the effect of elevation on movement,
visibility, and weather.

A world can have named geographical features, such as a bay, mountain,
desert, or valley.
Geographical features never have any direct effect on your game,
but some interfaces may use them to help describe locations,
in phrases like @code{"1 hex NW of Broken Hill"}.

A world can have people living in some or all of its cells.
People belonging to a side report everything
they see in their cell to their side.
Some types of units will change the people's side to the
unit's, if that unit is of the proper type.

@node Units, Materials, Worlds, Playing Xconq

@section Units

@dfn{Units} can be almost anything:
adventurers, armies, balloons, bicycles, dragons, triremes, spiders,
battleships, bridges, headquarters, cities.
Units move around, manufacture things,
fight with other units, and possibly die.
They are the playing pieces of @i{Xconq}.

Units have a location, either in out in the open or inside
some other unit.
In games that define connections (like roads), a unit may be
on the connection rather
than on the predominant terrain of the cell.
(Think of a truck on a bridge.)
Some games may also have airborne and subsurface units.
There may be more than one unit in the open in a given cell,
up to a game-defined limit.
A unit inside another unit will be called
an @dfn{occupant} in a @dfn{transport},
even if the ``transport'' is a type that can never move.

A unit either belongs to a side, or else it is considered @dfn{independent}.
Independent units do not do very much.
In the more complex names, the unit's side merely represents the
current ownership, and the unit may have a range of feelings
towards each side, including its current one.
In those games, it is possible for a unit to be a traitor!

Units can have a name, full name, a title, and a number,
as appropriate to the situation.
The name is an ordinary name like ``Joe Schmoe'' or ``Cincinnati'',
while the full name might be something like ``Joseph P. Schmoe''.
The title is a form of address such as ``Lord''.
The unit number, if used, is an ordinal that is maintained
for each side and each unit type,
so you can have both a ``1st national bank'' and
a ``45th infantry division'' on your side.
Names and numbers are always optional, and can usually be changed at any time
during the game.

Every unit starts out with a
number of @dfn{hit points} or @dfn{hp} representing
how much damage it can sustain before dying.
Certain types of units, such as armies and fleet of ships,
have multiple @dfn{parts}, which means that damage to them
reduces their effective size.
Multi-part units can merge with and detach from each other.
Damaged unit may recover their hp on their own, or else
repairable by explicit action.

In addition to occupants, a unit can also carry materials
(food, fuel, treasure, etc).
These materials are known as the unit's @dfn{supplies}.
Supplies are used up by movement, combat, and by just existing, and are
gotten either by producing them or by transferring them from some other unit.
Some games start units out with lots of supplies, while in others
you have to acquire them on your own.

What a unit can do at any one time depends on the @dfn{action points} or
@dfn{acp} available to it.  Each sort of action - movement, construction,
repair, etc - uses up at least one action point, and possibly more.
A unit with an acp of 0 can never do anything on its own,
although other units can still manipulate it.
Also, not every type of unit can do every type of action;
this is also defined by the game design.
Section xxx lists all the types of actions that are
possible in @i{Xconq}.

You can lose a unit in many different ways:
in combat, by running out of essential supplies,
by being captured, by revolt, by garrisoning a captured unit,
by leaving the world, or in accidents.

@node Materials, Sides, Units, Playing Xconq

@section Materials

In @i{Xconq}, @dfn{materials} are basically bulk inanimate stuffs,
like food or fuel.
They are kept in units or in cells,
up to a maximum defined by the game.
Materials may be provided as part of the initial game setup,
or else produced by units and cells.
They are consumed by construction,
movement, or merely in order to surive.
You can also move materials around from unit to unit,
or (in some games) let the laws of supply and demand
move them for you.

In a few games, possession of a material type may figure into your
score (your gold for instance).
In other games, there are no types of materials at all.

@node Sides, Moving Units, Materials, Playing Xconq

@section Sides

Each player in @i{Xconq} runs a @dfn{side}.
The concept of ``side'' is somewhat abstract in @i{Xconq};
units in a game belong to sides,
but the sides themselves are not attached to any particular unit
(with the partial exception of ``self-units''; see below for details).
Side often represent countries, but not always.

It is important to be clear about sides and players.
A side is a part of the simulated world, while a player
is the actual real-world person or program that is playing the side.
You yourself are always the player, but in one game you may play the
German side, and in another the Klingon side.
During a game, there will always be a player for each side,
and vice versa.  The distinction is most important
during setup; you can swap players between sides.

Each side can have a name and associated parts of speech,
such as a noun for individuals on the side and an adjective
to describe anything belonging to the side.
Sides can also have emblems and colors that are used in displays.
Some game designs preset all this, while others let you
personalize as desired.
See the @i{Xconq} document for your system to learn how to do this.

@subsection Interaction Between Sides

In games with two players, your interaction is usually pretty simple,
i.e. bash each other.  In games with many players, some human, some
mechanical, it is possible to have a variety of relationships, ranging
from complete trust to complete hatred.

One thing you can do is to make your side be controlled by another side.
This is basically surrendering, because the controlling side can
manipulate any of your units as if they were its own.  The controlling
side also has the option of allowing or forbidding you to move your
own units.  The relationship is strictly one-sided, and only the
controlling side can release the controlled side.  (Note that this
is a way to do governors, where one player is the main boss and
is helped by several other players acting as governors, usually
with agreed-upon responsibilities.)

A less extreme, but still very close, relationship is trust.  This is
like a close ally - you can enter each other's transports, you share
view data, and so forth.  Trust is a two-way relationship; both you
and the other side each have to declare you want to trust the other.
Trust can be unilaterally withdrawn.

If you don't want to declare a special relationship with another side,
but still want to make some sort of adhoc arrangement, you can create
an @dfn{agreement}.  An agreement is a sort of generalized treaty;
it consists of a number of @dfn{terms} agreed to by a number of
@dfn{signers}, which are sides.  Agreements may be public or secret,
and you can declare them to be enforced by @i{Xconq} if the terms
are in a form it understands (obviously, an agreement that just says
``help each other out'' cannot be evaluated by the program).

To make an agreement, you ask the interface to create one, fill in its
terms, possibly give it a name, and make up a list of proposed signers.
@i{Xconq} will then ask each signer for a tentative signature, if all
tentatively sign, then the agreement becomes genuinely signed and goes
into effect immediately.  All sides that are to know about the agreement
will be informed of its terms. [have both public and secret terms?]

Some interfaces may allow players to copy and modify a proposed and
circulate it along with the original.  The proposing side may also
withdraw a proposal, but cannot modify it without having it signed again
by everybody involved.

Once in effect, an agreement cannot be modified, and it cannot be
removed unless it includes a term that provides for this.

Each term of an agreement can have one of several forms:

A text string.  This is not interpreted in any way
and could be a comment, preamble, or whatever.

A true/false expression.  This must always be true for the agreement
to be valid.

A statement of an action.  This action will be performed at the instant
that the agreement goes into effect.

An if-then statement.  If the condition is true
while the agreement is in effect, then the action will be performed.

[need some examples]

@subsection Trade with Other Sides

You can specify the nature of the trading relationship with other sides.
The basic theory is that traders are businessfolk and don't care much about
politics; they will do business with anybody.
However, a player can define relationships with other sides via tariffs.
A tariff is a per-side per-material value that is the percentage of material
that will be claimed from the amounts going both to and from units on a side.
[does this mean we need both import and export tariffs?]
A tariff of zero means free trade, while negative is allowed and amounts to
a subsidy.

@subsection Tech Levels

In some game designs, technology and research are important.
These games give each side a set of @dfn{tech levels}
or just @dfn{tech}, one for each type of unit.
The tech level represents the technological knowledge needed to
see, operate and build a type of unit.
Tech levels never decrease (they can in real life, but only over
very long time intervals),
and they can be increased by research and espionage.

There are several thresholds that you must reach to do things with a
unit.  First there is a @code{tech-to-see}, below which you will not even
be aware of the existence of a unit (consider barbarians unable to see
spy satellites overhead).  Then there is a @code{tech-to-use},
which you must have in order to do anything with the unit.
The @code{tech-to-understand} and @code{tech-on-acquisition} are
points at which your side can increase its tech level just by owning
a unit, and finally the @code{tech-to-build} is what you must
have to create new units of the given type.

See the appropriate sections below to find out how to do research and
espionage to increase your tech level.

@subsection Side Classes

In some games, several sides may be very similar, while being very
different from other sides in the same game.
These similar sides can be given the same @dfn{side class}.
Units may then be restricted to be usable only by the sides in
a particular class.  (Note that this is different from tech level,
which allows units to be used by any side that has managed to acquire
a sufficiently high tech level.)

@subsection Self-Units

A @dfn{self-unit} is one that represents your whole side in some way.
For instance, in a dungeon exploration game, your ``side'' might consist
of an adventurer (you), your possessions, your followers, and perhaps more.
In such a case, if the adventurer dies or is captured, then the game is
over for that side.

[describe change of self-unit etc?]

@subsection Personalizing Your Side

[Whole section is hard to understand]

In order to tell everybody apart, it is possible to define and
record your side name and a distinct emblem.  You can have different
identities for different scenarios, and a default that applies to all
others.

The name is a proper noun such as "Poland",
the noun is what you would call an individual,
such as "Pole", the plural is for more than one,
and <adj> is the adjective for things on that side, such as "Polish".
The color scheme is a comma-separated list of color names,
and <image name> names some sort of image file (like a bitmap).

The image may be of any size and combination of colors, with the caveat
that it may not always work correctly.  For instance, two subtly different
shades may get fused into a single solid color.  The emblem should also be
small enough to fit reasonably into unit icons.
As a rule, most national flags will fit into a 7x5 rectangle,
and coats of arms into a 7x9 region.
The color scheme should be useful by itself,
when the unit icons are too small to fit the emblem.

@i{Xconq} will not allow you to have the same name, color, or emblem as
another player in the same game.

The interface-specific side configuration uses the favored mechanism
for that interface (if one is defined).
You should check with the interface documentation for more details.

@node Moving Units, Automation, Sides, Playing Xconq

@section Moving the Units

Once the first turn begins (and any pre-move backdrop activity has happened,
see below), you can begin looking at the display and moving your units.
Depending on the game design and startup options, you may or may not
be moving simultaneously with the other players.
If not, then the players move sequentially, in the order that their
sides are listed in any display.
Although all units conceptually act simultaneously,
they actually act one at a time, in an order determined by
various factors that will be described later.

@subsection Turn Setup

First, @i{Xconq} computes the number of action points
available to each unit.
Each unit gets an increment of action points equal to its
@code{acp-per-turn}.  Actions during a turn reduce this down;
when it reaches a value less than the cost of any action,
unit cannot do anything more until the next turn.

The range of action points for a unit is
normally 0 up to the value of @code{acp-per-turn},
but the parameters @code{acp-min} and @code{acp-max}
may allow for an extended range.
You use this range by allowing a unit to accumulate extra action points
by doing nothing for several turns,
or to recover from an activity that used
many action points all at once.
Think of this as a sort of temporary action ``debt''.
Units in debt at the beginning of a turn cannot act
during that turn.

@subsection Types of Actions

Actions are the most basic kinds of things your units can do.
During play, the interface will usually give you
capabilities that are easy to use, such as the ability
to drag a unit and have it try to get there somehow,
but all such input
eventually breaks down into sequences of actions.
You will therefore find it useful to know all the types of
actions available.

Movement Group:

@itemize @bullet
@item
@i{Move to} a given location.
The unit being moved may be in a transport or out in the open,
the destination is any location in the open (this will usually,
but not always, be an adjacent cell), and may be at any altitude
allowed for the unit.

@item
@i{Enter} a given transport.  The transport need not be on the same
side as the entering unit.

@end itemize

Combat Group:

@itemize @bullet

@item
@i{Attack} a given unit.

@item
@i{Overrun} a given location.  This basically means ``attempt to occupy
the destination, chasing everybody else out''.

@item
@i{Fire at} a given unit, possibly with a given material.

@item
@i{Fire into} a given location, possibly with a given material.

@item
@i{Capture} a given unit.

@item
@i{Detonate} at a given location.

@end itemize

Construction Group:

@itemize @bullet

@item
@i{Research} a given unit type.

@item
@i{Tool up} to build a given unit type.

@item
@i{Create} a unit of the given type.  The unit will usually be incomplete.

@item
@i{Build} a given unit towards completion.

@item
@i{Repair} a given unit.

@end itemize

Unit Manipulation Group:

@itemize @bullet

@item
@i{Disband} a given unit.

@item
@i{Move part} of a unit, either to another given unit,
or creating a new unit.

@item
@i{Change side} of a given unit to a given side.

@item
@i{Change type} of a given unit to a given type.

@end itemize

Material Manipulation Group:

@itemize @bullet

@item
@i{Produce} a given quantity of a given material type.

@item
@i{Transfer} a quantity of a given material type to a given unit.

@end itemize

Terrain Manipulation Group:

@itemize @bullet

@item
@i{Add terrain} of a given type to a given location.

@item
@i{Remove terrain} of a given type from a given location.

@end itemize

In general, all of these actions allow the acting unit to do the action on
another unit.
For instance, a transport can pick up or drop off a non-moving unit.

Not all interfaces can be guaranteed to allow the most general forms
of all these actions!

@subsection Movement

Movement into a cell is easy to request, but each game will
have many rules constraining possible moves, depending both
on the unit and the terrain it is moving over.
Certain kinds of terrain cost extra points to enter, leave,
or cross.  The destination must almost always be adjacent
to the unit's current location.

The other kind of action is to enter/leave a transport.
The only argument is the unit to enter,
but again the constraints are complicated.
The transport must have sufficient space,
both the entering unit and the transport must have sufficient
mp and acp to complete the move,
and they must be able to cross intervening terrain.

In some games, you may be able to make one of your units leave the
world entirely.  Sometimes this will seem like a good idea, perhaps
to keep a trapped unit from falling into enemy hands, or because
you win the game by leaving through a designated place.
To do this, you just direct your unit (which must already be at the edge
of the world) to move into one of the cells along the edge.
If the departure is allowed, then the unit will simply vanish
and be out of the game permanently.

In other games, you may be able to do a @dfn{border slide}.
This is where a unit can jump to a non-adjacent cell if the
two cells have a border whose endpoints touch the starting
and ending cell.  This is typically allowed in games so that
ships can go through narrow straits.

@subsection Combat

@quotation
War is a matter of vital importance to the State; the province of life
or death; the road to survival or ruin.  It is mandatory that it be
thoroughly studied.  -- SUN TZU (ca 400 BC)
@end quotation

There are two basic kinds of combat, each with two versions.
A unit can attack or overrun, meaning that it comes to grips with
an enemy in some way,
or it can fire, meaning that it keeps its position and throws
rocks or whatever at a target.

@dfn{Attack} is directed at a particular unit,
while @dfn{overrun} is a more complex action where the unit
attempts to clear enough units from a given location
so that it can move into it.

The general idea is that a unit wishing to attack picks a position
or unit to attack, @i{Xconq} computes the defender's response,
then the outcome is determined.

In many games, that will be the end of a fight.
In others, the units remain engaged in a @dfn{battle},
and they cannot do any other type of action
until they have disengaged completely.

@dfn{Firing} can happen at long ranges, up to the @code{range} of a unit.
It may or may not involve using a specific material as ammunition;
if the game gives you a choice, you will have to choose which,
or else all possible types will be used.
You can @dfn{fire at} a specific unit if you can see it,
otherwise you will have to @dfn{fire into} a cell.
[presumably with less effectiveness]

Some units are capable of capturing other units, with a probability depending
on the types of both units involved.  If the capture attempt is successful,
the capturer will move into the cell if possible, either as occupant or
transport.  In some games, the capturer may be all or partially disbanded,
to serve as guards.
Capture may also occur as a side effect of a normal attack.

Detonation is a special kind of ``combat'' available to some units.
The action requires a location - either the unit's position or a nearby cell.
Upon detonation, the detonating unit may lose some hp and even die
(changing to its ``wrecked type'', if defined, or else vanishing).
At the same time, it makes one hit on any units within its
radius of effect.  Detonation may also be triggered automatically,
such as by damage to the unit or even by another unit appearing nearby.

@subsection Research

@dfn{Research} increases a side's tech for the unit type
being researched.
Although you can only research a specific type of unit,
some game designs allow for a crossover effect, where increases in the
tech level for one type also increases the level in others.

You can have more than one researcher researching the same type,
and thereby speed up your progress, but some games put a ceiling
(@code{tech-per-turn}) on how much progress you can make in one turn.

@subsection Toolup

@dfn{Tooling up} prepares a unit to create or construct the desired type.
As with research, game designs may allow a crossover effect for tooling.
Tooling may also decline gradually over time; this is called
@dfn{tooling attrition}.

@subsection Construction

Construction of a unit happens in two steps; creation and
building towards completion.
Most interfaces will also schedule research and toolup
actions if a unit is told to build something that is still beyond its
capabilities.

@dfn{Creation} is the actual step of bringing a new unit into existence.
If the new unit is @i{complete}, then it can be used immediately.
If not (the usual case), then the incomplete unit will exist and belong
to your side, but be unable to do anything at all.
Incomplete transports cannot have any occupants,
unless they are types capable of completing the transport.

@dfn{Completion} is achieved by doing completion actions on the unit.
Multiple units can all work on completing the same unit,
but they must be sufficiently close, within a range defined by the game
(usually the same or an adjacent cell).

It is @i{usually} the case that the same unit will be able to both
create and complete a unit, but if not, you will have to pay special
attention to your construction plan, since an incomplete unit cannot
(usually) do anything to help itself along.  In some games, there
is a level of completion past which the unit will start working
on itself automatically, and eventually become complete without any
further action.

Note that multi-part units will be considered ``complete'' when just one
of their parts is completed.  Again, most interfaces will have the
builder continue growing the just-completed unit as long as it sticks
around.

@subsection Repair

@dfn{Repair} restores lost hit points to a unit.
Repairs can be done by the damaged unit itself,
if it is not too badly damaged,
or by another unit that is close enough nearby.

Some games also feature automatic hit point recovery,
so you don't have always to remember to do explicit repair actions.

@subsection Disbanding

@dfn{Disbanding} is voluntary loss of hp, ultimately resulting
in the disappearance of the unit.
Most games only allow it for a few types of units.

Units with occupants can disband,
but only if the occupants are unaffected by the
action.  If unit would vanish or lose transport capacity,
then the occupants must be disbanded or removed first.

@subsection Moving Parts

In games where units are of variable size, you can shift one or
more parts of a multi-part unit to another unit.

@subsection Changing Side

@dfn{Changing side} means moving a unit from the control of one
side to another.  Not all types of units will allow this!

@subsection Changing Type

A few games allow a unit to change its type voluntarily.

@subsection Production and Transfer

@dfn{Production} is how a unit can produce a quantity of a material.

In many games, units already have a @dfn{base production} that is
the amount of material that they produce automatically each turn.
This will often depend on the terrain, so that explorers in the
forest will always ``produce'' enough water to drink each turn,
but will start to use up their water supply when in the desert.

Often there will be plenty of some type of material in the world,
but the problem is getting it from the units that have a lot,
to the units that need it badly.  The @dfn{transfer} action is
how you move supply from one unit to another.

As with production, many games have some automatic transfers
set up.  For instance, games involving aircraft generally refuel
them automatically whenever the aircraft has landed in a place
with fuel to spare.

@subsection Changing the Terrain

In some games, units can add or remove borders, connections,
or coatings, or may be able to change the overall type of terrain
in a cell.

@node Automation, Climate Backdrop, Moving Units, Playing Xconq

@section Automation of Units and Sides

Specifying the exact sequence of actions and their operands
for every single unit would be mind-numbingly complex.
It's not very realistic either!
Therefore,
@i{Xconq} includes several levels of automation for human players.

The elements of automation are the @i{task}, the @i{plan}, the
@i{doctrine}, and the @i{strategy}.  These are related to each
other by @i{goals}.

@dfn{Tasks} are single activities of a unit that require one or more
actions to accomplish.  Examples of tasks include moving to a
given position, or waiting 15 turns to be picked up by a transport.

A @dfn{plan} is the unit's object that expresses its decided-upon behavior.
Elements of a plan include a type, goal, and task queue,
as well as more specific slots, such as a pointer to the unit
currently under construction.
All units that can do actions have a plan.

The @dfn{doctrine} is the set of parameters governing how the side will play
and how its units should work generally.  For instance, per-unit
doctrine specifies the point which a unit low on supply should
start to look for a place to replenish itself.

The @dfn{strategy} and associated subobjects is what an AI
uses to make all the decisions about what to do.  This object is not
directly visible, unless the AI is acting as your assistant
and the interface includes such a display.

Of all these types of objects, only the doctrine can be manipulated
directly;  all others are implicitly changed as a result of
player commands, which are different for each interface.

@subsection Doctrine

Players can set doctrine and use it in subsequent games, either for
all games or just particular ones (see side config section).

@itemize @bullet

@item
wait-for-orders

This is true if a unit should wait for explicit orders to be issued.
If false, the unit should make up some sort of default plan and follow it.

[add rest of doctrine]

@end itemize

@subsection Standard Types of Tasks

Tasks that a unit can do include:

@itemize @bullet
@item
Wait for an explicit command.

@item
Stand sentry at its current location.

@item
Move in the given direction.

@item
Move to within a given distance of the given location.

@item
Move towards another given unit.

@item
Patrol an area around one or two given points.

@item
Attempt to hit a unit at a given location.

@item
Attempt to capture a unit at a given location.

@item
Resupply.

@end itemize

@subsection Time Limits

One reason to be concerned about automating your units is that some game
designs define real-time limits on the length of a game.
For instance, the game might be set to end in one hour,
a single turn might be limited to always last at most 2 minutes,
or your side might be limited to 15 minutes of playing time,
in the manner of a chess clock.
If such limits are in effect, your display should be able to show you
how much time you have left at any moment; pay attention!

When you run out of time, you are not automatically taken out of the game,
but you can no longer give any orders.  Units that are already on
automatic will continue to act.

The game design may give you a limited number of
``timeouts'' that you can call to stop the clock.
The timeout ends when you order a unit to do something.

@node Climate Backdrop, Economy Backdrop, Automation, Playing Xconq

@section Environmental Conditions

Some games include @i{environmental effects},
which includes what we normally think of as weather;
the temperature, clouds, wind, rainfall, snowfall,
and snow cover on the ground.

The temperature falls in a range specified by the game, and may be
computed in different ways depending on the game design,
but typically depends on terrain, latitude,
the severity of the seasons, and elevation.
Temperature may also vary randomly from turn to turn and cell to cell.
The contribution of each of these to the final
temperature is up to the game design, as is the @emph{effect} of
temperature. [explain effects]

Cloud layers may appear in levels above the surface.
Their chief effect is to affect the seeing of units on the other
side of the clouds.

Wind affects the weather by causing clouds and storms to move around.
Certain unit types, such as sailing ships and balloons,
may depend on the wind to move around.

Games may define that the world represents part of a tilted sphere,
and that poles and equator correspond to various latitudes,
which has the effect of producing seasons.
The game specifies the temperature extremes for poles and equator,
for both midsummer and midwinter, then the weather phase interpolates
to get the average temperature for the current turn and at each latitude
in the world.

@node Economy Backdrop, Randomness Backdrop, Climate Backdrop, Playing Xconq

@section Economy

The economy in @i{Xconq} is based upon materials; if a game does not
define any material types at all, then there is no economy.

@subsection Consumption

Units consume their supplies, both in the course of existence,
and by motion/combat.
The rate depends on game and unit type; it consists of an overhead
consumed each turn without fail, and consumption for each cell of movement.
The total is a max, not a sum, since units with a constant consumption
rate are not likely to need additional supplies to move (consider foot
soldiers who eat as much sitting around as they do walking).
Supplies may also be consumed for production and repair, again depending
on game and unit types, but this consumption happens during the build phase.
Consumption is not affected by the situation of the consuming unit;
armies in troop transports eat just as much as when in the field.

@subsection Movement of Materials

Excess production is discarded, unless it can be unloaded into the
producer's occupying units, or distributed to nearby units via
@dfn{supply lines}.  Supply lines automatically exist between units
that are close enough (as decreed by the game), and there is no
need for explicit manipulation.

Supply line length depends on the game and the units on both ends,
but is not affected by the intervening terrain.
Supply redistribution is managed by logistics experts, who are ignorant
of the war effort and seek only to even everything out.
The redistribution method is rather adhoc; units try to get rid of all
their excess supply, and try to take up supply from other units within
supply range.  Each direction is controlled independently, so for instance
airplanes can get automatically refueled from a nearby city, but not from
each other.  No unit will transfer all of its supply via supply lines.
Normally units in the same cell can exchange supplies, but some games
can disable this behavior, so that explicit transfer using the give and
take commands is always necessary.

@node Randomness Backdrop, Scoring, Economy Backdrop, Playing Xconq

@section Random Events

Some games may include @dfn{random events}.
These are usually rare, but not always - be sure you know the odds!

@subsection Accidents

For some types of units in some types of terrain,
there is a chance for an accident to wreck or eliminate the unit instantly.
This depends on both unit type and terrain type.
If the accident occurs, the unit is wrecked or eliminated
along with all its occupants.

@subsection Attrition

Attrition is ``slow death'';
it takes away some number of hit points each time it occurs.
The rate of attrition depends on unit type and terrain or transport type.

@subsection Revolt/Surrender

Revolts and surrenders are really the same sorts of occurrence; a unit
changes sides spontaneously, perhaps to independence, perhaps to the side
of a nearby unit.
[???]
Occupants will either change over or be killed.
Any plans will be cancelled.

Surrender only occurs if a unit is
capable of capture is present.  The capturing unit does not move.
Occupants of the surrendering unit also change over or die.
Chance of surrender is increased by low unit morale.

@node Scoring, , Randomness Backdrop, Playing Xconq

@section Scoring

Different games can have different ways for players to win or lose.
Some games may not have any scoring at all.
You should be aware of this @emph{before} you start to play the game!

In @i{Xconq}, scoring is implemented by a game design's @dfn{scorekeepers}.
Each scorekeeper tests some sort of condition and/or maintains
a numeric score.
Scorekeepers also define when they run
(perhaps only during certain turns or certain times within a turn)
and which sides to look at.
Each scorekeeper is independent of the others,
so it only takes one to decide that you won or lost.

In a game with many players, winning and losing can be
a complicated issue; read the conditions carefully.
A scorekeeper can also decide to declare a game to be a draw and
end it on the spot.

Once a side has won, it is out of the game.
Some scorekeepers only allow one winner, others allow several;
in those cases, the scorekeeper will say what happens to the winning
side's units.

Once a side has lost, it cannot be brought back into a game, even if
another side tries to give it some more units or otherwise to reverse
things.

Finally, some games may record everybody's final scores into a file.

@subsection Last Side Wins

The most common form of scoring in @i{Xconq} is called
@dfn{last-side-wins}.  It is basically a fight to the death;
any side that loses all of its units loses, and the last side
with any units remaining is declared the winner.
It is possible that more than one side loses all its units
at the same time, in which case the game is declared a draw.

Since this would sometimes lead to bizarre stalemates (a submarine
could hide at sea, thus preventing the side from losing, for instance),
many games also define a @dfn{point value} for units.
In such cases, @i{last-side-wins} makes a side lose when the sum
of point values of all its units is zero.

[following sections should help player interpret scorekeepers]

@subsection Occupation

@subsection Unit Counts

@section Playing Hints

Informal alliances frequently happen in games involving more than two people,
so I have a few words of advice.  First, an alliance between two of the
players is almost certain in a three-person game, and inevitably
results in the "odd man out" being quickly defeated.  In four-person
games, the alliances could be decided after looking at the map via
a command-line option,
so that one pair is not hopelessly separated.  Five or more players is
going to be a free-for-all of formal and informal alliances.
Some scenarios are designed with a particular number of players in mind.

@section Technical Details

The coordinate system is ``oblique'',
with the X-axis in the usual horizontal,
and the Y-axis vertical, but tilted to the right at a 60-degree angle.
@example
      Y
     /
    /
---------X
  /
 /
@end example